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BACKGROUND OF THE INVENTION 

The present invention relates to a translation system for translating a 
source program into a machine language program by using an electronic 
computer and, more particularly, to a translation system of the type mentioned 

15 above in which an object program common to a plurality of target computers 
or machines of different types can be profitably employed. 

Systems for allowing programs described in high-level languages to be 
executed on the target computers or machines are generally classified into 
two systems respectively referred to as a compiler system and an interpreter 

20 system. 

In the compiler system, a program described in a high-level language is 
translated into a machine language program oriented to a target computer, 
and the machine language program is executed straightforwardly by the target 
machine. 

25 On the other hand, in the case of the interpreter system, a language 
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(referred to as the intermediate language) which differs from the machine 
language of the target computer is prepared along with a program (referred to 
as the interpreter) which is adapted to interpret and execute the intermediate 
language program on the target computer. In other words, the high-level 
5 language program is translated into the intermediate language program which 
is then executed by the target computer or machine on which the interpreter 
program runs. 

One of advantages of the compiler system over the interpreter system 
is seen in the greater speed of program execution which can be explained by 
10 the facts mentioned below. 

(1) In the interpreter system, there are required in addition to the execution 
of a machine language program corresponding to an intermediate language 
program, allocation of the processings for the intermediate language codes as 
well as address calculation for operands and others. On the other hand, in the 

15 compiler system, such processing allocation and address calculation are 
rendered unnecessary because the machine language program can be 
directly executed in a straightforward manner. 

(2) In the compiler system, sparing or deletion of some of the processings 
is possible by taking into consideration the context of program and 

20 characteristics of the target computer (i.e. program optimization can be 
realized). In contrast, the interpreter can only execute the intermediate 
language program as it is because of its universal application to intermediate 
languages and thus the interpreter is not in the position to allow any 
processing to be spared or omitted in consideration of the program context. 

25 Besides, since the characteristics of the target computer or machine are not 
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reflected onto the intermediate language program, it is impossible to speed up 
the processing by resorting to, for example, mapping of specific variables 
described in a high-level language to the registers incorporated in the target 
machine. 

5 On the other hand, as to the usage of a program destined to be 

executed repeatedly, there has heretofore been adopted either one of the two 
methods mentioned below. 

(1 ) According to a first method, the compiler system is adopted, wherein 
the machine language program obtained through the translation is preserved 

10 or stored so as to be repeatedly executed in a straightforward manner. 

(2) According to the other method, the interpreter system is adopted, 
wherein the intermediate language program is stored for allowing repeated 
executions thereof by the interpreter. 

When one program is to be executed repeatedly, the compiler system 
15 is adopted by an overwhelming majority from the viewpoint of reducing the 
time involved in execution of the program. However, the compiler system 
suffers from the shortcomings described below. 

(1 ) It is necessary to provide the compiler for translating a source program 
into a machine language program for each type of target machine, which 
20 means that not only the quantity of compilers to be developed must 

necessarily increase but also the overhead involved in maintenance and 
extension is significantly increased because the maintenance and extension 
must be performed so as to be compatible with the machine types of the 
target computers. 

25 (2) When one and the same program is to be executed by a plurality of 
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target computers of different machine types, compilation (i.e., translation from 
a source program to a machine language program) is required for each of the 
machine types of the target computers, which results in the overhead for the 
management of the machine language programs increasing greatly. 
5 (3) In an environment in which a plurality of computers of different machine 
types are connected to a network, a number of machine language programs 
which correspond to the number of the computers connected to the network 
are required for one and the same source program, which gives rise to 
problems with regards to the version management and disk space availability. 
10 Moreover, difficulty will be encountered in distributed execution of one and the 
same program. 

(4) Some of the systems are used actually often operated with only the 
machine language program without any source program being given. In such 
system, exchange or switching and alterations of the component machines is 

15 difficult to realize. At present, progress in hardware technology facilitates 
implementation of highly sophisticated computer architecture. Nevertheless, 
inheritance of the machine language program resources imposes a serious 
limitation to alteration or modification of computer architecture. 

For overcoming the disadvantages of the compiler system mentioned 

20 above, a system may be conceived in which an intermediate language 
program which is independent of any specific machine is employed for the 
purpose of preservation or storage and management of the program, wherein 
upon execution, the intermediate language program is translated into a 
machine language program of a target machine for thereby realizing high- 

25 speed processing, i.e., a system which adopts only the advantageous 
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features of the compiler system and the interpreter system in combination. In 
the present state of art, however, there is known no real system which 
realizes the concept mentioned above. 

For details of the compiler system and the interpreter system, 
5 reference may be made to "A. Aho, R. Seti and J. Ullman: Compilers. 
Principles, Techniques and Tools", Addison-Wesly, 1986, pp. 1-24. 

In order to allow a machine-independent intermediate language 
program (i.e. intermediate language program which is independent of any 
specific target machine or computer) to be adopted as a form for preservation 
10 and management of a program to be executed repeatedly, it is required that 
the intermediate language program can be executed at a speed comparable 
to that of execution of the machine language program in the existing compiler 
system. 

To this end, fulfillment of the requirements mentioned below will be 
is indispensable. 

(1 ) The intermediate language program which is in the form suited for the 
preservation and management as described above is not executed by the 
interpreter but translated into a machine language program immediately 
before execution. 

20 (2) In the course of translation or conversion of the intermediate language 
program into the machine language program, optimization of the program is 
carried out by taking into consideration the characteristics of the target 
computer which is to execute that program. 

With the present invention, it is contemplated to provide a consolidated 

25 or integrated system which can realize the requirements mentioned above, 
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i.e. to provide a practical form of an intermediate language for storage and 
management of the intermediate language program together with a practical 
method of effectuating the translation of the intermediate language program 
into the machine language program upon start of execution of the program 
5 while optimizing the machine language program for the target computer. 

In this conjunction, it is noted that the intermediate language code 
designed for the interpreter system cannot be used as the intermediate 
language codes for realizing what is contemplated with the present invention 
for the reasons described below. 
10 (1 ) The intermediate language code for the interpreter system contains no 
information required for optimization to be effectuated upon translation into 
the machine language program because the intermediate language codes are 
not designed on the premise that it undergoes the optimization by the 
interpreter. 

is (2) The computers may be globally classified into a register machine which 
includes a finite number of registers and in which operations are performed 
primarily on the registers and a stack machine which includes operation 
stacks, wherein the operations or computation are performed primarily on the 
stack. In the current state of the art, a majority of the existing computers are 

20 implemented as the register machines. By contrast, many of the intermediate 
languages for the interpreter systems are designed on the presumption of 
operation on the stack because of the ease in designing the intermediate 
language codes and the interpreter. Of course, it is not absolutely impossible 
to convert the on-stack operation to the operation on the registers. However, 

25 great difficulty will be encountered in translating the intermediate language 
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program for the stack machine into an efficient and effective machine 
language program for the register machine, when considering the fact that the 
values on the stack are inherently assumed to be disposable, while those on 
the registers should rationally be used repetitively as far as it is possible in 
5 order to make the most of the registers with high efficiency. 

SUMMARY OF THE INVENTION 

It is therefore an object of the present invention to provide information 
processing method and system in which an intermediate language program 

10 independent of any specific computer or machine is used for storage, 

management and the like purpose and translated into a machine language 
program appropriate for a target machine immediately before execution of the 
program by the target machine. More specifically, it is contemplated with the 
present invention to provide an information processing system which can fulfill 

15 the requirements described below. 

(1 ) In designating a register machine as the target machine (i.e., 
execution-destined computer), the intermediate language program should 
have such an instruction sequence in which the existence of registers is 
presumed at the very basic level of the intermediate language program. 

20 Besides, in the course of translation up to the intermediate language program, 
optimization should have been effectuated to a possible extent. 

(2) Upon translation into the machine language program from the 
intermediate language program, a register utilization method should be able to 
be optimized. More specifically, utilization of the registers should be so 

25 determined that the number of times the instructions for loading and storing 
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values to and from registers should be reduced to a minimum while allowing 
unnecessary instructions to be deleted. Moreover, information requisite for the 
optimization should be derived from the intermediate language program. 
(3) In some cases, a specific sequence (a series of plural instructions) in 
5 the intermediate language program can be replaced by an instruction peculiar 
to the target machine. In such a case, it is generally preferred, from the 
standpoint of efficiency to effectuate the replacement by one machine 
language instruction. Accordingly, when a machine language instruction 
corresponding to a succession of intermediate language instructions is made 

10 available by the target machine, a machine language program should be 
generated such that the corresponding machine language instruction 
mentioned above can be used. 

Aspects of the present invention in general may be 5 summarized as 
follows. 

15 1. System structure 

According to an aspect of the present invention, a system for 
translating a source program into a machine language program for an 
execution-destined computer or target machine is composed of three 
subsystems. They are: 

20 (1 ) a compiler: a subsystem for generating an object program (referred to 
as abstract object program) which is independent of the type of target 
machine, 

(2) a linker: a subsystem for linking together a plurality of abstract object 
programs generated by the subsystem compiler into a single abstract object 
25 program, and 
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(3) an installer: a subsystem for translating the abstract object program 
output from the linker into a machine language program for the target machine 
(which may also be referred to as the target computer, execution-destined 
machine or the like). 

5 2. Form of object program 

In order to make the object program common to a plurality of target 
machines, an abstract register machine (also referred to as ARM or Arm in 
abbreviation) having a plurality of registers is presumed, wherein an 
instruction sequence for the abstract register machine or ARM is made use of 

10 as a basic part of the common object program (referred to as the abstract 
object program). 

The abstract register machine or ARM has features mentioned below. 

(1 ) The ARM has a plurality of abstract registers. (Although the number of 
the abstract registers is infinite in principle, limitation is imposed depending on 

15 the form of the abstract object program in practical applications.) 

(2) The ARM has as the instruction executing functions a register-memory 
data transfer function, function for performing operations on the registers 
(such as four arithmetic operations, logical operations, shift operations, 
comparisons) and an execution control function (such as unconditional 

20 branch, conditional branch, call and restoration of subprograms, etc.). 

(3) Memory addresses are represented by symbol names rather than 
numerical values. 

The reason why the instruction sequence of the abstract register 
machine or ARM including a plurality of registers is made use of as the basic 
25 part of the common object can be explained as follows: 
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(a) In order to speed up the translation of the object program into machine 
language programs appropriate to the individual target machines, 
respectively, it is desirable to reduce, as much as possible, semantic gaps 
between the object program and the machine language. In conjunction, it is to 

5 be noted that the computation machine used widely at present is a register 
machine having a plurality of registers. Accordingly, by presuming the abstract 
register machine having as an instruction set a semantically common part of 
the instruction sets of the conventional register machines, overhead involved 
in the semantically meaningful translation can be reduced, whereby the 

10 translation to the machine language program can be speeded up. 

(b) In the register machine, one of the keys for speeding up execution of 
the machine language program is effective utilization of the registers. Thus, by 
regarding the abstract register machine or ARM as a target machine for the 
compiler, the latter can generate instruction sequence which can make use of 

15 the registers to the greatest possible extent. 

The abstract object program is composed of: 

(a) instruction sequence ARM, 

(b) pseudo-codes such as definitions of labels concerning branch, entry, 
variable and constant, embedded information for the optimization, and 

20 embedded information for the debugging at the source program level, 

(c) generation control specifiers (indicating allocation/deallocation of 
abstract registers and selection of an ARM instruction sequence in the state in 
which the abstract registers have been allocated), and 

(d) dictionaries of variable names and index names for reference in the 
25 debugging at the level of the source program. 
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Although the type of the abstract register can be indicated by the 
generation control specifier for the abstract registers, it is impossible to 
designate to which of the registers in the real machine the indicated abstract 
register correspond. In this manner, the registers can be surfaced up in the 
5 abstract object program independent of the type of the target machine. 

3. Specification of target machine 

In order to allow the machine language programs for the target 
machine to be generated from the abstract object program, two types of 
10 information mentioned below are prepared for the installer: 

(i) indication concerning the usage of the register in the target machine 
(types and number of the usable registers), and 

(ii) translation rules for translation of the instruction sequence pattern of 
the ARM into an instruction sequence pattern for the target machine. 

is At this juncture, it should be mentioned that the ARM instruction pattern 

and that of the target machines are each composed of a plurality of 
instructions. 

The instructions of the ARM and those of the target machine are not 
set a one-to-one correspondence relationship, the reason for which is 

20 explained as follows. 

(1 ) In a strict sense, the ARM instruction set cannot constitute a common 
part of real machine instruction sets. Accordingly, there may arise such a 
situation in which the instruction corresponding to that of the ARM is absent in 
the instructions executed by a target machine. In that case, it is necessary to 

25 realize one ARM instruction by several instructions of the target machine. 
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(2) There may arise a situation which is reverse to that mentioned above. 
In other wards, the instruction sequence executed by the target machine may 
include an instruction which corresponds to a sequence of several ARM 
instructions, as exemplified by a register-memory operation instruction and 
5 the like. In this case, the ARM instruction sequence is handled as one target 
machine instruction, because the processing speed can be enhanced by 
decreasing the number of instructions to be executed by the target machine. 
4. Method of translating the abstract object program into a machine 
language program for a target machine. 
10 The installer includes a table for managing correspondence between 

the abstract registers of the ARM and the real registers of the target machine 
(this table will hereinafter be referred to as the register management table) 
and performs operations mentioned below. 

(1 ) In response to an abstract register allocation command for the abstract 
15 registers in the abstract object program, the installer attempts to establish 

correspondence between an abstract register and a real register. In that case, 
when there exists a real register for which correspondence with other abstract 
register has not been established within a range described in register usage 
indication of the target machine specifications, i.e. where there is found an 
20 idle real register, correspondence is established between the aforementioned 
abstract register and the idle real register. 

(2) In response to a register releasing or freeing command contained in 
the abstract object program, the installer clears the correspondence relation 
between the abstract register and the real register (i.e. deallocation is 

25 executed by the installer). 
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(3) With the aid of the generation control specifier contained in the abstract 
object program, the installer checks whether or not an abstract register is set 
in correspondence relation with a real register, whereon an ARM instruction 
sequence is selected. 
5 (4) For the ARM instruction sequence thus selected, the installer applies 
translation rules contained in the target machine specifications for translating 
the ARM instruction sequence pattern into a target machine instruction 
sequence pattern, to thereby generate a target machine instruction sequence 
corresponding to the selected ARM instruction sequence while replacing the 

10 abstract register identification number by that of the real register. 

(5) For the target machine instruction sequence thus generated, the 
installer converts the symbol name representing the memory address into 
numeric addresses. 

The compiler which may be implemented by applying compiler 

15 techniques known heretofore serves for translation of a source program into 
an abstract object program. Simultaneously, the compiler performs 
optimization at the source program level as well as optimization of the ARM 
instructions for which utilization of the registers is required. 

In this way, the installer generates a machine language program for a 

20 target machine from an abstract object program in conformance with the 
target machine specifications. 

Thus, the machine language program for the target machine as 
generated by the system according to the invention has the features 
mentioned below. 

25 (1 ) Optimization at the source program level as well as optimization of the 
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register utilization is realized by the compiler. 

(2) Due to the real register allocation function of the installer, the registers 
incorporated in the target machine can be made use of to a maximum extent. 

(3) Owing to the instruction sequence pattern replacing capability or 

5 function of the installer, it is possible to replace a succession of plural ARM 
instructions by one instruction for the target machine, to thereby make the 
most of high performance by the target machine. As a result, an object 
program can be shared by a plurality of different machine type computers 
while maintaining the execution speed and performance which are equivalent 
10 to those involved in the execution of the machine language program 
generated by the prior art system (prior art compiler system). 

BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 is a diagram schematically showing a general arrangement of a 
15 translation system for translation of a source program into a machine 
language program according to an embodiment of the present invention; 

Fig. 2 is a diagram schematically showing a structure of a compiler for 
generating, from a source program, an abstract object program in the form of 
a sequence of abstract register machine instruction; 
20 Fig. 3 is a diagram showing a relation between an abstract register 

machine instruction sequence and a machine language instruction sequence 
for a particular machine; 

Fig. 4 is a view for illustrating types of generation control statements 
contained in an abstract register machine instruction; 
25 Fig. 5 is a view for illustrating a format of an abstract register machine 
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instruction; 

Fig. 6 is a view for illustrating relations between address modes and 
operands in abstract register machine instructions; 

Fig. 7 is a first part of a view showing specifications of a machine 
5 language generation instruction contained in the abstract register machine 
instruction; 

Fig. 8 is a second part of the view showing specifications of a machine 
language generation instruction contained in the abstract register machine 
instruction; 

10 Fig. 9 is a third part of the view showing specifications of a machine 

language generation instruction contained in the abstract register machine 
instruction; 

Fig. 10 is a fourth part of the view showing specifications of a machine 
language generation instruction contained in the abstract register machine 
15 instruction; 

Fig. 1 1 is a fifth part of the view showing specifications of a machine 
language generation instruction contained in the abstract register machine 
instruction; 

Fig. 12 is a sixth part of the view showing specifications of a machine 
20 language generation instruction contained in the abstract register machine 
instruction; 

Fig. 13 is a view for illustrating an example of the source program 
which is input to the compiler shown in Fig. 2; 

Fig. 14 is a first part of a view showing an example of the abstract 
25 object program corresponding to the source program shown in Fig. 13 in the 
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state not yet optimized; 

Fig. 15 is a second part of the view showing an example of the abstract 
object program corresponding to the source program shown in Fig. 13 in the 
state not yet optimized; 
5 Fig. 16 is a third part of the view showing an example of the abstract 

object program corresponding to the source program shown in Fig. 13 in the 
state not yet optimized; 

Fig. 17 is a view for illustrating a process of calculating priorities of 
register allocations in the abstract object program shown in Figs. 14 to 16; 
10 Fig. 18 is a flow chart for illustrating a procedure for generating priority 

bit vectors representing the priorities for the register allocation in the compiler 
shown in Fig. 2; 

Fig. 19 is a flow chart for illustrating a process of eliminating a common 
expression as executed as a part of optimization processing by the compiler 
15 shown in Fig. 2; 

Fig. 20 is a first part of a view showing an example of the abstract 
object program corresponding to the source program shown in Fig. 13 for 
illustrating an abstract register machine instruction sequence resulting from 
optimization processing; 
20 Fig. 21 is a second part of the view showing an example of the abstract 

object program corresponding to the source program shown in Fig. 13 for 
illustrating an abstract register machine instruction sequence resulting from 
optimization processing; 

Fig. 22 is a flow chart illustrating a processing for effectuating 
25 movement of intra-loop invariants; 
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Fig. 23 is a view showing usages of physical registers in a target 
machine A; 

Fig. 24 is a view for illustrating correspondence relations between the 
physical registers and the abstract registers; 
5 Fig. 25 is a flow chart for illustrating a translation into a machine 

language with the aid of pattern matching technique; 

Fig. 26 is a view showing a part of machine instruction selecting rules 
oriented for the target machine A; 

Fig. 27 is a view showing a state in which physical registers in the 
10 target machine A are allocated to the abstract object program shown in Figs. 
20 to 21; 

Fig. 28 is a view showing a machine language program which is 
generated from the abstract object program shown in Figs. 20 and 21 by an 
installer for the target machine A; 
15 Fig. 29 is a flow chart for illustrating processings performed internally of 

the installer; 

Fig. 30 is a schematic block diagram showing a structure of the 
installer together with inputs and an output thereof; 

Fig. 31 is a view showing usages of the physical registers in a target 
20 machine B; 

Fig. 32 is a view showing a state in which the physical registers of the 
machine B are allocated to the abstract object program shown in Figs. 20 and 
21; 

Fig. 33 is a view showing a part of the machine instruction selecting 
25 rules oriented for the machine B; 
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Fig. 34 is a view showing a state in which the physical registers of the 
machine B are allocated to the abstract object program shown in Figs. 19 and 

20; 

Fig. 35 is a view showing an example of machine language program 
generated by the installer for the machine B from the abstract object program 
shown in Figs. 19 and 20; 

Fig. 36 is a block diagram showing a structure of debugging system to 
which the installer according to an embodiment of the invention is applied; 

Fig. 37 is a flow chart for illustrating operation of the debugger; 

Fig. 38 is a view showing an example of a display command; 

Fig. 39 is a flow chart for illustrating the display processing; 

Fig. 40 is a view showing an example of a break-point setting 
command; 

Fig. 41 is a flow chart for illustrating a break-point setting processing; 

Fig. 42 is a view showing an example of execution command; 

Figs. 43 is a flow chart for illustrating execution processing and shows 
details of the processing in a step 5128 shown in Fig. 37; 

Fig. 44 is a view showing an example of the source program which is 
subject to the debugging; 

Fig. 45 is a view showing an example of a source/abstract 
object/machine language correspondence table; 

Fig. 46 is a block diagram showing a structure of an IC card device 
incorporating an installer according to the invention; 

Fig. 47 is a pictorial view showing an outer appearance of an IC card 
system; 
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Fig. 48 is a top plan view of an IC card; 

Fig. 49 is a flow chart for illustrating execution of an abstract object 
program incorporated in the IC card; 

Fig. 50 is a block diagram showing a system in which one and the 
5 same abstract object program contained in an IC card is executed by a 
plurality of IC card systems having different CPUs, respectively; 

Fig. 51 is a block diagram showing a system in which abstract register 
machine code programs are shared by computer systems of different machine 
types which are linked together through a network; and 
10 Fig. 52 is a block diagram illustrating, by way of example, replacement 

of a computer system in which an abstract register machine program is 
employed by another type of computer system. 



DESCRIPTION OF THE PREFERRED EMBODIMENTS 
15 Now, the present invention will be described in detail in conjunction 

with exemplary or preferred embodiments by reference to the accompanying 
drawings. 

Fig. 1 is a diagram showing an exemplary structure of a translation 
system for translating a source program into a machine language program, 
20 according to an embodiment of the present invention. 

The translation system includes three subsystems. 

They are a compiler 1001 , a linker 1002 and a installer 1003, 
respectively. 

When a source program 1004 is input to the compiler 1001 , the 
25 compiler 1001 performs a syntax analysis, a semantic analysis, an 
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optimization processing (described hereinafter) and others on the source 
program 1004, at the representation level of the source program, to thereby 
output an ArmCode (Abstract register machine code) program 1005 which is 
an abstract object program. At this juncture, it should be noted that the 
5 ArmCode program is provided according to one of the aspects of the present 
invention, and the specifications of the ArmCode program will hereinafter be 
elucidated in detail by reference to Figs. 4 to 12. As to the compiler 1001, a 
structure thereof will be described by referring to Fig. 2, while the optimization 
processing performed by the compiler will be described later on in detail by 

10 reference to Figs. 13 to 22. 

The linker 1002 receives the ArmCode program 1005 generated from 
the source program 1004 by the compiler 1001, another ArmCode program 
1007 generated similarly from another source program 1006 by the compiler 
1001 and an ArmCode program library 1008, and performs solution of 

is problems concerning a relation between routines referenced to by the 

programs and a relation between variables or constants referenced to as well 
as integration of data areas and that of instruction areas, as a result of which 
a linked ArmCode program 1009 is output from the linker 1002. The function 
of the linker itself is equivalent to a part of the function of the object program 

20 linkage editor known heretofore if the ArmCode program is regarded as a 
conventional machine language. Accordingly, any further description of the 
linker 1002 will be unnecessary. 

The installer 1003 is loaded with the linked ArmCode program 1009 to 
perform a real register allocation, selection or generation of machine 

25 instructions and a machine-dependent optimization with the aid of register 
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usage designation 1019 and machine instruction generating rules 1020 which 
are contained in specifications information 1010 of a target machine or 
computer A 1012 and then the installer 1003 develops a machine language 
program 101 1 on a memory of the target machine A 1012. The processings 
5 carried out by the installer also constitutes one of the aspects of the present 
invention and will be described in detail later on by reference to Figs. 23 and 
30. The computer or machine A 1012 executes the machine language 
program 1011 developed in the manner as mentioned above. 

In case the ArmCode program 1014 generated from the source 
10 program 1013 by the compiler 1001 requires no linkage with anyone of 

ArmCode programs and the ArmCode program library ioo8, as shown in Fig. 
1 , the installer 1003 can be loaded with the ArmCode program 1014 
straightforwardly to thereby deliver the same to a corresponding machine 
language program. 

15 The installer 1003 generates the machine language program for the 

computer of the machine type A hereinafter referred to as the machine A. On 
the other hand, another installer 1015 serves to generate a machine language 
program 1016 for a machine B 1017 by using specifications information 1018 
of the target machine B. In this manner, the translation system now according 

20 to the present invention is capable of generating from the same linked 

ArmCode program 1009 or the single ArmCode program 1014 a plurality of 
machine language programs such as the exemplified by the machine 
language programs 1011 and 1016 for a plurality of target machines such as 
those exemplified by the computers A 1012 and B 1017 to thereby allow these 

25 target machines to execute the relevant programs, respectively. As will be 
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appreciated from the above description, the translation system according to 
the invention can generate, from the same ArmCode program, a plurality of 
machine language programs for a plurality of target machines or computers of 
the specifications differing from one another, an example of which will 
5 hereinafter be described in more detail by reference to Figs. 31 to 35. 

Fig. 2 is a diagram showing an exemplary structure of an abstract 
register machine compiler (generally denoted by 3100) according to the 
embodiment of the present invention. Referring to the figure, a source 
program 3102 undergoes at first a syntax analysis and a semantic analysis 

10 by a syntax/semantic analysis section 3104 of the compiler 3100 to be 

translated into an intermediate language program 3106, while information of a 
variety of symbols used in the source program 3102 is entered in a symbol 
table 3108. An intermediate language optimization section 3110 of the 
compiler 3100 performs a control flow analysis and a data flow analysis on the 

15 intermediate language program 3106 to thereby realize a global optimization, 
as a result of which there is generated an ArmCode program 31 12 as a 
sequence of abstract register machine code instructions prior to an 
optimization processing 3114. Subsequently, the optimization processing 
31 14 on the ArmCode program is carried out to generate an abstract object 

20 program 31 16 as the optimized ArmCode-R instruction sequence. Concerning 
the methods of the syntax analysis, the semantic analysis, the control flow 
analysis, the data flow analysis and the global optimization, reference may be 
made to "A. V. Aho, R. Sethi and 3. D. Ullman: Compilers;Principles, 
Techniques and Tools", Addison-Wesley Publishing Co., 1986, pp. 1-24. 

25 One of the aspects of the present invention can be seen in a structure 
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of the abstract register machine code ArmCode instruction. In other words, 
this ArmCode instruction has a structure and contents which are suited 
for the processings contemplated by the present invention, i.e., a high speed 
translation of the abstract object program to a machine language program 
suited for the target machine upon loading of the abstract object program. A 
system of the ArmCode instructions is common to a number of reduced 
instruction set computers (RISC) machines and it will hereinafter be referred 
to as the ArmCode-R (Abstract register machine Codes for RISC machines) 
system. 

The ArmCode-R instructions are suited for the computers having the 
features mentioned below. 

(1) Operations are performed only between or among the registers. 

(2) Memory access is made only with the load/store type instruction. 

(3) A base register is incorporated. 

(4) The number of registers which can be employed for operations 
are sixteen or more. 

(5) Immediate constants are available. 

(6) All the instructions can each be represented by one word (32 bits). 
Each of the ArmCode-R instructions is not the very machine instruction 

for a specific target computer but can easily be translated to the machine 
instruction. The representation format of each ArmCode-R instruction is 
characterized by the features mentioned below. 

(1 ) The register is not represented as a physical register but as an 
abstract register. 

(2) A memory address is specified based on not a numerical value 
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address but a symbol name. 

(3) The memory is addressed on a byte basis. 

(4) The instruction is of a fixed length. 

In the following description, it should be understood that the expression 
5 "ArmCode" represents "ArmCode-R" unless specified otherwise. 

Fig. 3 is a diagram for illustrating correspondence relations between the 
ArmCode program and the machine language program for the target machine 
shown in Fig. 1. As mentioned previously, the source program 2910 
undergoes the translation and linkage processing through a compiler/linker 

10 section 2912 to be translated into an abstract object program 2920, which is 
represented by an ArmCode instructions sequence composed of instructions 
for the abstract register machine. 

Each ArmCode instruction is similar to one for a model machine or 
computer common to many of the currently used computers, and includes an 

is abstract operator 2921 , an abstract register designation 2923 and an abstract 
memory/ constant designation 2925 as typical or representative items. The 
abstract operator represents the content of one of instructions incorporated 
universally in many computers, such as load/store for instructing data 
transfers between a memory and a register, an arithmetic operation as 

20 addition or subtraction and others. The abstract register name designation 
indicates a register in the abstract register machine, wherein no limitation is 
imposed to the number of the abstract registers, differing from a case of a real 
computer. The abstract memory/constant designation 2925 can be handled 
similarly to that for a memory address and a constant in the real computer 

25 except that the former is free from any limitation in respect to the address and 
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magnitudes of a value of the constant. 

The ArmCode instruction sequence 2920 is translated into a machine 
language instruction sequence for a target machine through the installer 
provided in association with the target machine. By way of example, the 
5 instruction sequence 2920 shown in Fig. 3 is translated into a machine 

language instruction sequence 2950 for a machine A when an installer 2930 
for the machine type A is used while it is translated into a machine language 
instruction sequence 2960 for a target machine B when an installer 2940 for 
the target machine B is used. The ArmCode instructions and real machine 

10 instructions are not always in one-to-one correspondence. In general terms, 
an instruction sequence including m ArmCode instructions is translated into 
an instruction sequence including n real machine instructions. An operator, a 
register designation and a memory/constant designation contained in each 
machine instruction are inherent to the machine to which that machine 

is instruction is oriented. For example, an operator 2951 , a register designation 
2953 and a memory/constant designation 2955 of each machine instruction of 
the machine language program 2950 oriented for the machine A are inherent 
to that machine A, while an operator 2961 , a register designation 2963 and a 
memory/constant designation 2965 of each machine instruction contained in 

20 the machine language program 2960 for the machine B are inherent to that 
machine B. 

In the ArmCode instruction there are contained machine instruction 
generating instructions describing instructions which are actually to be 
executed by the target computer and structures thereof as well as generation 
25 control statements for controlling the generation of machine instructions, as 
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exemplified below: 

alloc(Ar10, RcArith,alc10, 5,0,0,xc0000000); 
if (alc10){ 

Load RegMd Ar10 Vbase OdDisp v;} 
5 Add RegCon AM 1 Noreg OdCi 6; 

As the machine instruction generating instructions, there may be 
mentioned the following types, which are written in an array in the abstract 
object program, being punctuated by semicolons. 

(1) Corresponding machine language instructions: 
10 (Load4, Store4, Add, Sub, etc.) 

(2) Pseudo-instructions representing program structures: 
(Start/Fend, Block/End, Stmt, etc.) 

(3) Pseudo-instructions for indicating the symbol names: 
(Entry, External, Label, Name, etc.) 

15 (4) Pseudo-instructions for designating the memory: 

(Dword, Dconst, Daddr, etc.) 
(5) Pseudo-instructions for designating the symbol information 
oriented for a debugger or the like: 
(Sinf, etc.) 

20 As is shown in Fig. 4, the generation control statement includes a 

conditional statement 3120, an assignment statement 3122 and a function 
reference statement 3124 and equations containing constants and simple 
variables can be used in the statements. As generation control functions, 
there can be used those functions mentioned below (refer to 3124 in Fig. 4). 

25 (1 ) function: "alloc" (abstract register name, register type, discriminant 
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variable, instruction number, preserve count, priority) 

This function "alloc" serves for requesting allocation to an abstract 
register designated by a first parameter a physical register of the type 
designated by a second parameter. The instruction number is an ordinal 
5 number identifying an abstract register using instruction preceding the 

allocation request. The preserve count represents the number of the registers 
to be preserved even after the register allocation. The priority represents the 
level of priority at which the register is to be allocated. The value of the 
discriminant variable designated by a third parameter is set to "1" when a 

10 physical register can be allocated at the time of the register allocation request 
while it is set to "0" when allocation of the physical register is impossible. 
(2) function: free (abstract register name) 

This function serves for making free (deallocating) the physical register 
from the abstract register designated by the first parameter. 

15 The priority for the register allocation is represented by a bit vector. 

The abstract register using instructions are assigned with the sequential 
instruction numbers, the abstract register to be used after q instructions as 
counted from the current instruction is correspondingly assigned with a bit 
vector including one bit of "1" placed after a succession of "Os" in a number of 

20 (p - 1 ). The priority is decided by regarding the bit vector as an unsigned 
integral value such that the unsigned integral value of greater magnitude 
represents a higher priority. Accordingly, the priority of the abstract register to 
be used immediately is higher than that of the abstract register used 
subsequently. For the abstract register to be used at a plurality of instructions, 

25 a bit vector resulting from the OR operation of those corresponding to the 
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plural instructions is assigned. Whenever progress is made from the current 
instruction, the bit vector is shifted to the left by one bit. The leftmost 
overflowed bit occurring upon shifting to the left is discarded with the 
rightmost bit being supplemented with "0". Accordingly, the priority of an 
5 abstract register becomes highest immediately before the use of that abstract 
register and is lowered after having passed the instruction where the abstract 
register is used. 

The bit vector representing the priority is not restricted to such structure 
in which the bit "1" is assigned to one instruction. By way of example, an 

10 abstract register using instruction sequence may be divided into segments 
each of a fixed length, and the segments are assigned with bits in one-to-one 
correspondence such that the bit is set to the value "1" when an abstract 
register of concern is used in the segment to which the abovementioned bit is 
assigned while otherwise being set to "0". In this manner, it is possible to 

15 express with a bit vector of a shorter length the using state of a register in the 
long instruction sequence. By setting the length of the segment to "1" (unity), 
the correspondence relation described above can be realized. 

In the case of an abstract register used through or in a loop, it is 
assumed that the register is used again or repeatedly at an interval 

20 corresponding to a length of the loop (or one-severalth of the length of the 
loop), and an original bit vector is shifted to the right by an adjusted count 
corresponding to the loop length (or one-severalth thereof) and the shifted bit 
vector is arithmetically added to the original bit vector. A resulting sum is used 
as the bit vector representing the priority of the abovementioned register. 

25 With the function "alloc" for allocating the physical registers to the 
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abstract registers, the priorities mentioned above are designated. The 
allocation is performed when the number of physical registers capable of 
accommodating the abstract registers having the designated priorities are 
available, while otherwise the allocation is not performed. The priority 
5 allocated previously to an abstract register becomes higher as the instruction 
which the register is used becomes closer while the former becomes lower 
beyond the instruction using that register. Thus, performance of the allocation 
can be determined by comparing the priority of a register with the priorities of 
the other registers. Overflowed abstract registers not allocated with the 
10 physical registers because of their low priorities are allocated to the memory 
areas. Concerning the priority, description in detail will be hereinafter be made 
by reference to Fig. 9. 

Fig. 5A is a view for illustrating a format of the ArmCode-R instruction. 
As can be seen in this figure, each of the ArmCode-R instructions 3130 is 
is composed of fields of an operator 31 32, an address mode 31 34, a first 
Operand 3136, a second operand 3138 and a third operand 3140, 
respectively, which have the contents mentioned below. 

Operator: name of the ArmCode-R instruction. 

Address mode: discrimination of operand form. 
20 1 st operand: register R1 , literal c1 or ArmCode address c1 . 

2 nd operand: register R2, literal c2 or ArmCode address c2. 

3 rd operand: memory address, displacement d3, literal c3, label c3, 

ArmCode address c3, etc.. 

As shown in Fig. 5B, the operands 3136, 3138 and 3140 are expressed 
25 as follows (refer to specifications of the machine language instruction 
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generating instruction): 

Register: abstract register number. 

Memory Address: absolute address, position of a 

variable name in a symbol table or 
5 abstract register number representing 

an address in the memory. 
Displacement: numerical value representing displacement relative 

to a base register. 
Literal: integer constant (numeral values, character code 

10 or positions of a character string table and a 

comment table to be subjected to operation). 
Label: item number of a label table LBL. 

ArmCode Address: position of instruction ArmCode 
The third operand is expressed in terms of a combination of a sub-item 
15 indicating type of the operand and a sub-item indicating the operand, as 
follows. 

Odsym s3: symbol table entry item s3. 
OdLab c3: label table (LBL) entry c3. 
Odci c3: intra-instruction scalar constant c3. 
20 OdCL c3: Intra-memory scalar constant indicated by c3. 

OdCS c3: string constant c3. 

OdGvar s3: temporal variable s3 generated by the compiler. 
OdDisp c3: displacement c3 

OdNo Null: indication of absence of the third operand. 
25 The first operand 3136 indicates a store destination position of the 
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execution result in the case of the instruction for a loading operation and a 
computing operation while it indicates a register which holds the data to be 
stored in the case of the instruction for a storing operation. In the case of a 
conditional branch instruction, the first operand 3136 indicates a register 
5 holding target data for the condition determination. The address mode 3134 
indicates the number of valid operands and the roles of them. 

Fig. 6 is a view for illustrating possible combinations of the address 
mode 3134 with the first operand (operand 1) 3136, the second operand 
(operand 2) 3138 and the third operand (operand 3) 3140 shown in Fig. 5. It 

10 can be seen from Fig. 6 what roles the operand 1 3172, operand 2 3174 and 
the operand 3 3176 play for each of the address modes 3170 such as 
RegReg, RegMI and others. In Fig. 6, blank column indicate that the relevant 
operands are not valid. When the operand is a simple register, the value of 
the register is utilized. When the operand represents a constant, the value 

15 thereof is utilized or set. When the operand represents an address register, 
the content of that address register is regarded as a memory address to be 
accessed. In case the operand designates the base register and a 
displacement, a value resulting from addition of the content of the base 
register and the displacement is regarded to be a memory address upon 

20 making access to that operand. In the address mode RegRCC, the constants 
c3 and c4 are regarded to be positive integers not greater than "255" and 
nested in the third operand. 

Figs. 7 to 12 are views showing specifications of the machine 
instruction generating instruction. Meanings of the symbols used in the 

25 specifications are as follows. 
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a address or constant a. When this value 

represents the address, a may be a numerical value c indicating 

the absolute address or a numerical value s indicating a position 

of the symbol table, 
[a]: content of the register or memory at the address a. 
a A : register or memory pointed by the content of the 
address a (having the address given by the content of a). 

( ): parenthesized expression is handled as one 
symbol. 

-> : assigning to right-hand register or variable. 

<- : assigning to left-hand register or variable. 
In the case of the instant embodiment of the present invention, there 
used the instructions mentioned below. 
Load instructions 3210 (Fig. 7) 
Load: Load one word data indicated by the 
operand 2 or 3 in the register indicated by the 
operand 1 . 

LoadB: Load one-byte data indicated by the 

operand 2 or 3 in the register indicated by the 
operand 1 with right justification. 



Mode-wise 


process 


ings: 


RegReg: 


R1 <- 


[R2] 


RegMI: 


R1 <- 


[R2 A ] 


RegMR: 


R1 <- 


[([R2]+d A ] 


RegMD: 


R1 <- 


[d] 
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RegCon: R1 <- c3 
RegAdr: R1 <- [R2]+d 

2) Store instructions 3220 (Fig. 7) 

Store: Store one-word data of the operand 1 in a 
location indicated by the operand 2 or 3. 
StoreB: Store the rightmost byte data of the 

operand 1 in a location indicated by the 

operand 2 or 3. 
Mode-wise processings: 
Reg Reg: [R1] -> R2 
RegMI: [R1] -> R2 A 

RegMR: [R1] -> ([R2]+d A 

RegMD: [R1] -> d 

3) Integer-class binary floating point instructions 3230 (Fig. 7) 

Add: Add the operand 2 to the operand 1 , and 
place the result of the addition in the 
operand 1 . Set a carry of "1" or "0" in 
dependence on presence or absence of overflow. 
Sub: Subtract the operand 2 from the operand 1 , and 

place the result of the subtraction in the 

operand 1 . Set a carry to "1" when the 

operand 2 is greater than the operand 1 and 

otherwise to "0". 
Mult: Multiply the operand 1 by the operand 2, and 

place the result of the multiplication in the 
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operand 1 . 

Div: Divide the operand 1 by the operand 2, and 
place the quotient in the operand 1 . 
UnsAdd: Same as the instruction Add except for 

unsigned addition. 
UnsSub: Same as the instruction Sub except for 
unsigned substruction. 
AddC: Same as the instruction Add except that the 

carry is considered in the addition. 
SubB: Same as the instruction Sub except that the 
borrow is considered in the subtraction. 
Mode-wise processings: 

RegReg: ([R1] op [R2]) -> R1 
RegCon: ([R1] op c3) -> R1 
where "op" represents an operator. 
4) Real number-class binary floating point instructions 3240 (Fig. 8) 
AddR: Add the operand 2 to the operand 1 , and 
place the result of the addition in the 
operand 1 . 

SubR: Subtract the operand 2 from the operand 1 , and 
place the result of the subtraction in the 
operand 1 . 

MultR: Multiply the operand 1 by the operand 2, and 
place the result of the multiplication in the 
operand 1 . 
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DivR: Divide the operand 1 by the operand 2, and 
place the quotient in the operand 1 . 
Mode-wise processings: 

RegReg: ([R1] op [R2]) -> R1 
RegCon: ([R1] op c3) -> R1 
where "op" represents an operator. 

5) Binary logical instructions 3250 (Fig. 8) 

And: Execute an AND operation of the operand 1 and the 
operand 2 and place the result of the AND 
operation in the operand 1 . 

Or: Execute an OR operation of the operand 1 and the 
operand 2, and place the result of the OR 
operation in the operand 1 . 

Xor: Execute an XOR or exclusive OR operation of the 
operand 1 and the operand 2, and place the result 
of the XOR operation in the operand 1 . 

Mode-wise processings: 

RegReg: ([R1 ] op [R2]) -> R1 

RegCon: ([R1] op c3) -> R1 

where "op" represents an operator. 

6) Unitary instructions 3260 (Fig. 8) 

Negate: Invert the sign of the operand 1 , and place 
the result of inversion in the operand 1 . 

Not: Invert the bits of the operand 1 , and place 

result of inversion in the operand 1 . 
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Mode-wise processing: 

Reg1: Computation is performed on the content of the operand 1, the 
result of which is left in the operand 1 . 

7) Comparison instruction 3270 (Fig. 8) 

5 Compar: Compare the content of the operand 1 with that of the 

operand 2 and set a condition code. 
Mode-wise processings: 

RegReg: If [R1] > [R2] then Gt, if [R1] = [R2] then Eq, 
if [R1]< [R2] then Lt. 
io RegCon: If [R1] >c3 then Gt, if [R1] = c3 then Eq, 

if [R1]<c3 then Lt. 

8) Condition test instructions 3280 (Fig. 8) 
TZero mode Reg1 : If "0", set the condition code to 

"Eq" and otherwise to "Ne". 
15 TBit mode RegCon: When the bit of [R1] at a position 
indicated by c3 of the third operand 
is "0", set the condition code to 
"Eq", while when it is "1" set the 
condition code to "Ne". 
20 9) Conditional branch instructions 3290 (Fig. 9) 

BrEq: When the condition code is "Eq", jump to a 

position indicated by the operand. 
BrNe: Unless the condition code is "Eq", jump to a 
position indicated by the operand. 
25 BrGt: When the condition code is "Gt", jump to a 
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position indicated by the operand. 
BrGe: When the condition code is "Gt" or "Eq", jump to 

a position indicated by the operand. 
BrLe: When the condition code is "Lt" or "Eq", jump to 
5 a position indicated by the operand. 

BrLt: When the condition code is "Lt", jump to a 

position indicated by the operand. 
In any of the cases mentioned above, the control is made to an 
immediately succeeding instruction unless the condition is met. 
10 Mode-wise processings: 

Const: Position indicated by the label table LBL[c3] 
is the address of the jump destination. 
RegR: [R2]+d is the address of the jump destination. 
10) Unconditional branch instruction 3300 (Fig. 9) 
15 Jump: Jump to a position indicated by the operand. 

Mode-wise processings: 

Const: Position indicated by the label table LBL[c3] 
is the address of the jump destination. 

RegR: [R2]+d is the address of the jump destination 
20 11) Subprogram reference instruction 3310 (Fig. 9) 

Call: After recording a return address, jump to a 

subprogram indicated by the operand. 

Mode-wise processings: 

RegMR: Placing the return address in R1 , 
25 jump is made to the address [R2]+d. 
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RegMD: Placing the return address in R1 , 

jump is made to a subprogram address indicated by the 
label table LBL[c3] 
Reg1 : After stacking the return address, jump to the 
address [R1]. 



12) Return instruction 3320 (Fig. 9) 

Return: Jump to the return address recorded by the instruction 

"Call" from the subprogram indicated by the operand. 
Mode-wise processings: 

Reg1 : Jump to the return address recorded in R1 . 
RegO: Fetching of the return address stacked by the instruction "Call" 
through 

LIFO scheme and jump to the fetched return address. 



13) Shift instructions 3330 (Fig. 10) 

These instructions are each to shift the content of the first operand R1 
to the left or right by a bit number n indicated by the second or third operand. 

ShiftL: Shift R1 to the left by n bits with the rightmost n bits 

being "Os". 

Shift R: Shift R1 to the right by n bits with the 

leftmost n bits being "Os". 
Mode-wise processings: 

RegCon: R1 represents a target register (i.e., register 
of concern) with c3 representing the bit 
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RegReg: 



number for the shift. 

R1 represents a target register with [R2] 
representing the bit number for the shift. 



5 14) Rotation instructions 3340 (Fig. 10) 

These instructions are each to rotate the content of the first operand 
R1 to the left or to the right by a number n of bits indicated by the second or 
third operand. 

RotL: Rotate R1 to the left by n bits. 
10 RotR: Rotate R1 to the right by n bits. 

Mode-wise processings: 

RegCon: R1 represents a target register with c3 

representing the bit number for the rotation. 
RegReg: R1 represents a target register with [R2] 
15 representing the bit number for the rotation. 

15) Bit manipulation instructions 3350 (Fig. 10) 

GetBit RegCC: Place the c3-bit data starting from 

the bit c2 of R1 in R1 with right 
justification. Left-hand bit portion 
20 of R1 is "0". 

GetBit RegRCC: Place the c3-bit data starting from 

the bit c2 of R2 in R1 with right 
justification. Left-hand bit portion 
of R1 is "0". 

25 PutBit RegRCC: Place the rightmost c4-bit data 
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of R1 in a c4-bit length field 
starting from the bit c3 of R2. 
Content of other bit field remains 
unchanged. 

5 16) Data conversion instructions 3360 (Fig. 10) 

ItoR RegReg: Instruction for integer-to-real 

conversion of the content of R1 , the 
result being placed in R2. 
Rtol RegReg: Instruction for real-to-integer 
io conversion of the content of R1 , the 

result being placed in R2. 
ItoD RegReg: Instruction for integer-to-double real 

conversion of the content of R1 , the 
result being placed in R2. 
is Dtol RegReg: Instruction for double real-to-integer 

conversion of the content of R1 , the 
result being placed in R2. 
1 7) Status switch instructions 3370 (Fig. 1 1 ) 

SaveSt RegMR: Save the current processor status 
20 in the memory, (saving information: 

program counter, status code, mask, 
etc.) 

LoadSt RegMR: Restore the processor status in 

accordance with information stored in 
25 the memory. 
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No-operation instruction 3380 (Fig. 11) 

Nop RegO: No execution of operation with a machine 
instruction occupying one word. 
Program structure representing pseudo-instructions 3390 (Fig. 11) 
Start Contl OdSym: Pseudo-instruction for starting object having a 

name (of the symbol table) indicated by s3. 
SubP Contl OdSym: Pseudo-instruction indicating the 
start of a subprogram indicated by s3. 
Block Cont: Block start pseudo-instruction. 
End ContO: Block end pseudo-instruction. 
Loops Contl OdLab: Pseudo-instruction indicating a 
head of a loop statement having a 
label indicated by LBL (c3) as a 
repetition starting point. 
Loope Contl OdLab: Pseudo-instruction indicating trail 
of a loop statement having a label 
indicated by LBL (c3) as a 
repetition starting point. 
Pend ContO: End of a subprogram or unit. (This 
"End" instruction is followed by 
"Define Storage" and "Define 
Constant" instructions and finally 
by "Pend" instruction.) 
Stmt Contl OdCi: Pseudo-instruction indicating a 

start position of a statement 
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having c3 as the statement number. 
20) Symbol name indicating pseudo-instructions 3400 (Fig. 1 1 ) 

Entry Contl OdSym: Pseudo-instruction indicating a name (of the 
symbol table) 

5 indicated by s3 as an entry name. 

Extern Contl OdSym: Pseudo-instruction indicating that 

a name (of symbol table) indicated by s3 is 
an external name. 
Label Contl OdLab: When c3 represents a LBL table 
10 number (user label) having a symbol table, the 

pseudo-instruction defining the name of the 
symbol table as the table name. When c3 
represents a LBL table number (generated label) 
having no symbol table, this pseudo-instruction 
is defining the generated label name ¥n as the 

label name. 

Label contl OdCL: Pseudo-instruction defining a 

constant name ¥¥Cm as the label 
name, when c3 is LRG table 
20 number a representing a memory constant 

Label Contl OdGvar: Pseudo-instruction defining a 

generated variable name ¥Tk as 
the label name, when s3 is symbol 
table number k representing a 
25 generated variable. 
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Name Contl OdSym: Pseudo-instruction equating a name 

(of symbol table) indicated by s3 
to the name of immediately 
preceding OpLabel. 

21) Memory designating pseudo-instructions 3410 (Fig. 12) 
Dconst Conti OdC1 : Constant definition for defining c3 

as an integer constant value. 
Dconst Contl OdCS: Constant definition for regarding 

c3 as a one-word character string. 
Dconst Contl OdCS: Constant definition for regarding 

c3 as a one-word character string 

constant. 

Dword Contl OdC1: "Define Storage" pseudo-instruction 
for securing a memory area of c3 
words. 

Daddr Contl OdSym: "Define Address" pseudo-instruction 

for the name (of symbol table) indicated by s3. 
MCode Contl OdC1 : Pseudo-instruction for generating a 
machine language MRT[c3] indicated by c3. 

22) Pseudo-instructions 3420 designating debugger-oriented symbol 
information, etc. (Fig. 12) 

PInf Contl OdC1: Pseudo-instruction indicating information of a 
program 

characteristic information table 
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resident at a position indicated by c3. 
SInf Contl OdC1 : Pseudo-instruction indicating symbol 

information at a position indicated by c3. 
Fig. 13 is a view showing an example of the source program 3102 
5 which is input to the compiler 3100 shown in Fig. 2. The source program 3102 
is composed of a declaration statement 3610 designating a global variable, 
designation of a name of a function 3614, a declaration statement 3616 of 
local variables in the function, a sequence of executable statements beginning 
with an executable statement 3620, etc. The numbers such as "1" positioned 
10 at the head of the declaration statement 3610, "10" at the head of the 

executable statement 3620 and the like represent the identification numbers 
of the respective statements. Fig. 14 to 16 show in combination an example of 
the ArmCode instruction sequence resulting from the translation of the source 
program shown in Fig. 13. The illustrated instruction sequence is not yet 
15 subjected to the optimization processing. A pseudo-instruction 3700 

designating symbol information in Fig. 14 corresponds to the declaration 
statement 3610 in the source program shown in Fig. 13. Similarly, a pseudo- 
instruction 3702 corresponds to the declaration statement 3616. Further, an 
ArmCode instruction sequence beginning with the executable statement 3710 
20 shown in Fig. 14 corresponds to the sequence of executable statement 

beginning with the statement 3620 of the source program shown in Fig. 13. 

Now, the description will be made more specific concerning the 
priorities of the registers with reference to Figs. 14 to Fig. 18. The instructions 
which use abstract registers in this ArmCode program are 3720, 3722 and so 
25 forth with an asterisk "*" at the head. The instruction "alloc" 3710 requests the 
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allocation of a physical register to an abstract register named "Vbase" with the 
priority designated as "0x62489700 + 0x00224897". The abstract register 
named Vbase is used by the instructions 3722, 3734, 3758, 3770, 3790, 
3828, 3846, 3850, 3856 and 3860. 32 instructions from the instruction "alloc" 
5 3710 are checked to determine whether or not these are an abstract register 
using instruction. Based on the checked result, a bit vector is generated in 
which "1s" are placed at the bit positions corresponding to the instructions 
which use the abstract register Vbase while "Os" are placed at the positions of 
the instructions which do not use the abstract register. As a result, the bit 

10 vector is represented by "01 10001001001000100101 1 100000000", which can 
be rewritten as "0x62489700" in the hexadecimal notation, as is shown in the 
instruction "alloc" 3710. In the case of the program shown in Figs. 14 to 16, 
there exists a loop from the instruction 3868 to the instruction 3728. This loop 
includes 23 instructions which use the abstract register. In the case of the 

15 instant embodiment, the number of the instructions using the abstract register 
and contained in this loop is divided by "3", and a value associated with the 
quotient when the remainder is "0" or (the quotient +1 ) when the remainder is 
not zero is defined as the adjust number. The bit vector of the abstract 
register "Vbase" used in the loop is represented by setting the second bit to 

20 "0" in the bit vector 3910, i.e. "00100010010010001001011100000000". By 
shifting this bit vector to the right by a number "8" resulting from division of 
"23" by "3" with the remainder being rounded up, there is obtained 
"00000000001000100100100010010111", as shown in conjunction 
with the instruction 3912, which is represented by "0x00224897" in the 

25 hexadecimal notation. Accordingly, the priority of the "Vbase" allocation 
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request is represented by a number "0x62489700 + 0x00224897", i.e., a sum 
of the addition of "0x62489700" and "0x00224897" as unsigned integers, as 
shown in the instruction "alloc" 3710 in Fig. 14. Through a similar procedure, 
the priority for the abstract register Ar5 can be computed, as is shown at 3918 
5 and 3920 in Fig. 17. 

The register allocation priority is not fixed but shifted to the left as the 
instructions are checked, as described previously. For example, at the 
position of the instruction 3732 located at the head of the loop which follows 
after the two register using instructions, the priorities of the registers "Vbase" 

10 and "Ar5" are shifted by two bits, respectively, resulting in that the priority of 
the register "Vbase" is "0x89225C00 + 0x0089225C", as shown at 3914 and 
391 6 in Fig. 1 7, while that of the register "Ar5" is "0x441 1 0000 + 
0x00441 100", as shown at 3922 and 3924. This priority is compared with the 
priority "0XE0000000" of the register "Ar6" whose allocation is requested by 

15 the instruction 3732. 

Fig. 18 is a flow chart for illustrating a procedure for generating the 
priority bit vector in the register allocation mentioned above. The priority bit 
vector of a register r is assumed to be represented by Pr. This bit vector Pr is 
first reset (step 3930). A succeeding Armcode instruction is fetched (step 

20 3932) and checked to determine whether it is the loop start instruction (step 
3934). When it is not the loop start instruction, then it is checked to determine 
whether the fetched ArmCode instruction is the register using instruction (step 
3936). When the answer of this decision step 3936 is affirmative (Y), the 
priority bit vector Pr of the register r is shifted to the left by one bit (step 3938). 

25 Subsequently, it is checked whether or not the register r is used (step 3940). 
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When the register r is used, "1 " is set at the rightmost bit of the priority bit 
vector Pr (step 3942). If otherwise (N), the rightmost bit of the bit vector Pr is 
set to "0" (step 3943). When the succeeding ArmCode instruction is a loop 
exit instruction or an instruction to free the register r, computation of the 
5 priority bit vector for the register r comes to an end (step 3944). If otherwise, 
the next ArmCode instruction is fetched, and the processing described above 
is repeated. 

When the ArmCode instruction as fetched in the step 3932 is 
determined to be the loop start instruction (step 3934), the priority bit vector of 

10 the register r is assumed to be represented by Lr within the loop under 
consideration and determined through the same procedure as described 
above (steps 3930 to 3944). Subsequently, the number of the abstract 
register using instructions contained in the loop is divided by three with the 
remainder. If there is any remainder, the quotient is rounded up. Then, the 

15 priority bit vector Lr is adjusted by shifting it to the right by a number of bits 
corresponding to the quotient or the rounded up quotient resulting from the 
above determination (step 3947). Thereafter, the adjusted priority bit vector Lr 
is added to the priority bit vector Pr of the instruction sequence including the 
loop (step 3948). In this way, the allocation priority bit vector Pr for one 

20 abstract register r can be computed. This processing is executed for each of 
the abstract registers. 

Fig. 19 is a flow chart illustrating a procedure of the object optimization 
for enhancing the efficiency of execution of a machine language program 
obtained from an ArmCode program according to an embodiment of the 

25 present invention. At first, an ArmCode instruction sequence of the ArmCode 
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program is divided into a plurality of basic blocks by punctuating the sequence 
at flow-in points and branching points of the control (step 3952). Each of the 
basic blocks has a feature that it is executed in a beeline from the start to last 
instructions. In the case of the example illustrated in Figs. 14 to 16, the 
5 instructions 3712 to 3722, 3724 to 3748, 3750 to 3778 etc., constitute the 
basic blocks, respectively, and a generation control instruction "bblock" 
indicating the inter-block link relation is added at the head. In the case where 
a certain basic block b is necessarily executed immediately after the 
execution of other basic block a, a basic block sequence which allows 

10 execution of the block b in succession to the basic block a to which the block 
b is linked is referred to as the extended basic block. By way of example, for 
the basic blocks starting from the instructions 3724, 3750 and 3780, 
respectively, a resultant block obtained by linking together these three basic 
blocks represents an extended basic block, because in each of the 

15 abovementioned basic blocks, the succeeding instruction is neccessarily 
executed immediately after the preceding instruction. The basic block 
beginning with the instruction 3840, for example, where extension is 
impossible because the preceding basic block and the succeeding basic block 
cannot definitely be established, is defined by itself as one extended basic 

20 block. Subsequently, a common expression or equation in the extended basic 
block is deleted. To this end, starting from the first extended basic block (step 
3954), the common equation in the extended basic blocks is picked out (step 
3956). The succeeding common equation is replaced by the content of a 
register or a variable representing the result of the common equation picked 

25 out precedingly (step 3958). This procedure is repeated until the last extended 



basic block has been reached (steps 3960, 3962). The abovementioned 
processing can be carried out by applying the algorithm disclosed in the Aho, 
Sethi and Uliman mentioned hereinbefore to the ArmCode instruction 
sequence. 

5 Figs. 20 to 21 are views showing in combination an ArmCode 

instruction sequence generated as the result of the above-mentioned 
processing of the instruction sequence shown in Fig. 14 to 16 and the 
optimization processing described below. Referring to Figs. 20 and 21 
together with Figs. 14 to 16, the optimization processing will now be described 

10 more specifically. In Figs. 14 to 16, the computation instructions 3758 and 
3760 for computing the value of the abstract register Ar8, the computation 
instructions 3790 and 3792 for computing the value of the abstract register 
Ar12 and the computation instructions 3828 and 3830 for computing the value 
of abstract register Ar15 are same as the computation instructions 3734 and 

15 3736 for determining the value of the abstract register Ar6, while the 

instruction 3764 for determining the value of the abstract register Ar9 is same 
as the instruction 3740 for determining the value of the abstract register Ar7. 
Similarly, the instruction for determining the register value Ar13 is same as 
that for the register value AM 1 , while the instructions for determining the 

20 register values Ar1 5 and Ar16 are same as that for determining the value of 
Ar5. Consequently, in the instruction 4098, the abstract registers Ar6 and 
Ar1 1 are reused, while in the instruction 4076, the register Ar7 is reused with 
the register Ar5 being reused in the instructions 4108, 4110 and 4112, as 
shown in Figs. 20 and 21 . In this manner, these abstract registers are 

25 replaced by those having the identical values, respectively, whereby the 
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instructions for determining the values of the abstract registers Ar8, AM 2, 
Ar15, Ar9, AM 3, Ar15 and Ar16 are deleted. Since the use frequencies of the 
abstract registers as well as the positions at which they are used change in 
accompanying the replacements mentioned above, the order of the priorities 
5 allocated to these abstract registers will vary correspondingly. The instructions 
"alloc" 4028 etc. shown in Figs. 20 and 21 indicate the processings mentioned 
above. 

An ArmCode program shown in Figs. 20 and 21 is derived from the 
ArmCode program shown in Figs. 14 to 16 by moving the intra-loop invariant 

10 equation outside of the loop and by effecting a branch optimization. Fig. 22 is 
a flow chart for illustrating the processing to this end. More specifically, 
referring to the figure, the loops are detected by a flow analysis (step 4202). 
Thereafter, starting from the innermost loop (step 4204), the intra-loop 
invariant equations are detected (step 4206) to be subsequently moved to the 

15 position immediately before the start of the loop (step 4208), evading 
repetition of the same computation within the loop. This processing is 
repeatedly executed up to the outermost loop inclusive (steps 4210, 4212). 
Since the values of the abstract registers Ar10, AM 1 and AM 7 shown in Figs. 
14 to 16 remain invariable in the loop which starts from the instruction 3728 

20 and ending at the instruction 3874, the instructions 3770, 3786 and 3860 for 
computing the values of these registers are moved to the position before the 
loop. The instructions moved in this way are indicated at 4038, 404k and 
4050, respectively, in Figs. 20 and 21. 

Further, referring to Figs. 14 to 16, the branch destination L3 (3806) of 

25 the conditional branch instruction BrGe (3778) includes an unconditional 
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branch instruction (3808) to L5. Accordingly, by determining the branch 
destination of the conditional branch instruction (3778) as L5, the 
unconditional branch instruction (3808) at L3 can be deleted. Additionally, the 
jump destination L4 (3812) of the unconditional branch instruction "Jump" 
5 (3802) includes the unconditional branch instruction (3814) to L5. Accordingly, 
by determining the branch destination of this instruction "Jump" as L5, the 
unconditional branch instruction (3814) at L4 can be deleted as well. As the 
result of the processings for enhancing the ArmCode instruction sequence 
execution efficiency for the abstract register machine as described above, 

10 there is obtained the ArmCode program shown in Figs. 20 and 21 . 

Next, description will be turned to a method of generating a machine 
instruction train for a real machine from an ArmCode instruction sequence i.e., 
ArmCode-R program generated in the manner described above. 

Fig. 23 is a view showing the types of the physical registers used in a 

15 machine A. More specifically, it is shown at 4260 that 8th to 23rd physical 

registers can be used for arithmetic operations "RcArith". Similarly, a "RcAddr" 
shown at 4262 indicates a register usable for address calculation, "RcSect" at 
4264 indicates a register used for indicating a section start position. Further, 
"RcReturn" at 4266 indicates a register used for restoration from a 

20 subprogram, "RcFuncval" at 4268 indicates a register used for placing therein 
a function value, "RcParm" at 4270 indicates a register used for placing 
therein a parameter, "RcNosave" at 4272 indicates a register which is neither 
saved nor restored upon reference to a subprogram, "RcTemp" at 4274 
indicates a register which is used temporally, "RcFixed" at 4276 indicates a 

25 register having the usage fixed, and "RcAny" at 4278 represents all the 



registers which are subject to the register allocation. 

Fig. 24 is a view for illustrating a part of correspondence relations 
between the physical registers of the machine A and the abstract registers. It 
is assumed that the number of the abstract registers 4280 is arbitrary while 

5 the number of the physical registers 4282 of the machine A is limited to "32". 
As can be seen in Fig. 24, there are established correspondences between 
the abstract registers (4284) "Funcval 1" and "Funcva11" for placing therein 
function values and the physical registers "2" and "3", as indicated by 4290 
and 4291. Similarly, correspondences are established between the abstract 

10 registers (8285) "ParamO", "Praml", "Paramp" for placing parameters 
therein and the physical registers "4" to "7", as indicated at 4291 and 4292, 
between the abstract registers for arithmetic operations (4286) "ArO", "Ar1 , 
... "Arq" and the physical registers "8" to "23", as indicated by 4292 and 4294, 
between the abstract registers (4287) "AddrO", "Addrl", "Addrr" for the 

is address calculation and the physical registers "16" to "23", as indicated by 
4293 and 4296, and between the abstract registers (4288) "SectO", "Sectl", 
"Sects" for indicating the section start positions and the physical registers 
"20" to "23", as indicated by 4295 and 4297, respectively. At this juncture, it 
should be noted that the number (p + 1 ) of the abstract registers for 

20 parameters, the number (q + 1 ) of the abstract registers for arithmetics 

operations, etc., are not restricted to the number of the physical registers but 
depend on the numbers of those registers which are required by the source 
program. As to the manner in which the abstract registers are allocated to the 
physical registers of the target machine, description will be made later on by 

25 reference to Figs. 26 to 29. 
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Fig. 25 is a diagram for illustrating a system for realizing the machine 
language generation through a pattern matching procedure. The illustrated 
system includes a pattern matching section 4556 and a table 4630 of machine 
instruction generating rules and operates to generate a machine language 
5 program 4650 in response to an ArmCode instruction sequence 4640 of an 
ArmCode program as input. The table 4630 stores input patterns and 
corresponding output patterns in one-to-one correspondence. Assuming now 
that one instruction 4602 is fetched from the instruction sequence 4640 an 
input pattern which coincides with the one instruction 4602 is searched for in 

10 the table 4630. In the case of the illustrated example, it is assumed that the 
instruction 4602 coincides with the input pattern i of the i-th generating rule 
4632. Accordingly, a machine instruction 4652 is generated from the input 
instruction 4602 in accordance with the generation pattern i of the i-th 
generating rule 4632. At this time, processing such as replacement of the 

is abstract register by the physical register, modification of the generating rule in 
consideration of the environmental conditions or the like is performed, as will 
be described hereinafter by reference to Figs. 29 to 35. 

Fig. 26 is a view showing a part of the machine instruction generating 
rules oriented for the machine A. As will be seen in the figure, the generating 

20 rules are parenthesized by brackets "{ )" after a corresponding ArmCode 
instruction sequence as shown at 4300, 4312 and others. Generation of the 
corresponding machine instructions is same as in C language. A symbol 
affixed at the head as shown at 4312, 4316 and others represents alternative 
between the sequences. The operands Reg1 , C, V, and others for the 

25 abstract register machine are expressed by $Regi, $C, $V and the like in the 



braces "{ }". 

Specifically, manners of generating a machine instruction for the 
machine A in correspondence to an abstract register machine instruction 
indicated at the first row 4300 for loading a constant are shown as rows of 
5 statements parenthetical by the brackets "{ }", starting from the row 4302. 
More specifically, the parenthesized statements describe that if the constant is 
"0" (zero) or greater than "0" and smaller than "65536", a machine instruction 
is to be generated in accordance with the statement 4304 and if otherwise the 
machine instructions are to be generated in accordance with the statements 

10 4308 and 4310. Fig. 28 shows a machine instruction 4500 which has been 
generated by applying this rule to the instruction 4030 shown in Fig. 20. In this 
example, the abstract registers are allocated with the physical registers in 
correspondence to the types of the abstract registers, as exemplified by 
allocation of the physical register $08 to the abstract register Ar5, the physical 

15 register $1 7 to the abstract register Ar6 and so forth, as shown in Fig. 27 at 
4400. 

Unless the number of the physical registers as requested are available, 
the allocation of the physical registers is not performed in response to the 
request by the instruction "alloc" but the physical register allocation 

20 processing is again executed at the time when the physical registers are 
actually used. By way of example, the instruction 4046 shown in Fig. 20 
indicates a physical register allocation request for the abstract register AM 7. 
However, this instruction contains a designation that the number of the 
physical registers to be preserved even after the allocation is "2". Besides, the 

25 priority of this instruction 4046 is relatively low. Accordingly, it may occur that 
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no physical register allocation is effected at this time point. In this case, the 
condition 4048 is not fulfilled. Accordingly, though no load instruction is 
generated in response to the instruction 4050, only the fact that the abstract 
register Ar1 7 represents the value of a variable n is recorded. Consequently, 
5 the comparison instruction 41 1 2 which uses the abstract register AM 7 is not 
yet allocated with any physical register. Thus, the physical register allocation 
processing is again executed upon processing this ArmCode instruction. At 
this time, the abstract register AM 7 has the highest priority to allow the 
allocation to be executed, whereby the load instruction for setting the value of 

10 the register AM 7 is also generated. Assuming in conjunction with this example 
that the abstract register Ari7 is allocated with the physical register $09, the 
instruction for loading the value of the variable n is generated in accordance 
with the record made at 4046. As a result of this, there are generated in place 
of the instruction 4526 in Fig. 28 

15 "sub $24, $08, $12" 

two instructions: 

"1w$09, n($16)", and 
"sub $24, $08, $09". 
In this way, if the abstract register allocated with no physical register is 
20 to be used, allocation of the physical register as well as setting a value there 
in is performed by using a function "gen" contained in the machine instruction 
generating rules shown in Fig. 26 such as the rule 4304 and others. 

The installer for the machine A generates the machine language 
program for the machine A from the abstract object program in the manner 
25 described above. At that time, selection of the optimal machine instruction 
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sequence and the optimal utilization of the physical registers are attempted in 
conformance with the target machine. In the case of the illustrated example, 
such measures are adopted that the machine instruction sequence to be 
generated is changed in conformance with the magnitude of a constant in 
5 accordance with the generating rule 4302 shown in Fig. 26 and that 
correspondences to the abstract registers are established by taking into 
account the number and the types of the usable physical registers, thereby 
allowing the physical registers such as $11 placed with a value to be used as 
many times as possible. In case there appear common equations in the 

10 generated machine language program in accompanying the expressions 

inherent to the target machine, the optimization processing such as deletion of 
repetitive computation for the common equation may be performed by 
resorting to the processing described hereinbefore in conjunction with Fig. 19. 
Fig. 29 is a flow chart for illustrating a processing flow of generation of 

15 the machine language program. After initialization (step 4552), one of the 
ArmCode instructions which constitutes a part of the abstract object program 
is fetched (step 4554), and the pattern matching is performed for checking to 
which of the patterns corresponding to the ArmCode instructions described in 
the machine instruction generating rules such as shown in Fig. 26 the fetched 

20 ArmCode instruction fits (step 4556). In case no fitting pattern is found, the 
matching resultant state is recorded (step 4560), and then the succeeding 
ArmCode instruction is fetched. When the fitting pattern is found, preparation 
for a machine instruction is made in accordance with description of the 
machine language generation for the fitting pattern (step 4562). When the 

25 register allocation is requested for the generated machine instructions as 
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described, the register allocation processing is performed (step 4564). When 
the memory allocation is requested, the memory allocation processing is 
executed (step 4566). For the request for generation of a real machine 
instruction, the corresponding processing is performed (step 4568). When 
5 addition of control information such as the debugging control information and 
others is requested, the control information as required is added to the 
machine language program (step 4570). In case the generation control 
information concerning the register allocation, memory allocation, selection of 
the instructions to be generated and/or the like is requested, the 

10 corresponding information setting processing is executed (step 4572). 

Subsequently, processing procedure proceeds to a next statement contained 
in the description of the machine language generation (step 4576). Execution 
of the above-mentioned processing steps 4566 to 4576 is repeated. When the 
operation(s) designated in the description of the machine language generation 

15 has been completed (step 4574), postprocessing for the generation 

processing for the pattern of concern is performed (step 4578). At this time, 
the matching state is altered so as to conform with the current state (step 
4580), and return is made to the pattern matching processing. When it is 
detected that the abstract object program has been entirely processed, the 

20 machine language generation processing comes to an end (step 4582). 

Fig. 30 is a schematic block diagram showing an internal structure of 
the installer for generating the machine language program from the ArmCode 
program in the manner described above. Referring to the figure, the installer 
4530 generates the machine language program 4549 from the ArmCode 

25 instruction sequence 4531 and the machine instruction generating rules 4532 
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for the target machine of concern. The pattern matching is principally 
effectuated by making use of a state transition table. To this end, the 
generating rules 4532 are transformed into a state transition table 4535 by a 
state transition table generation program 4533. The state transition table 4535 
5 contains actions to be executed and the ID number of the next state to which 
the transition is to be made for each combination of the individual ArmCode 
instructions as input and the state ID numbers. In the pattern matching based 
on the state transition, a suitable one of action routines 4538 is selected for 
execution by reference to the state transition table in dependence on the 

10 ArmCode instruction as input and the current sate. A state stack 4544 serves 
for recording the state transition history. On the other hand, a register usage 
designation table 4546 contains records concerning the register usage 
designations intrinsic to the target machine, while a register correspondence 
table 4548 is used for recording correspondence relations between the 

is abstract registers in the program being processed and the physical registers. 

Fig. 31 is a view showing types of the physical registers in a machine B 
which differs from the machine A in respect to the instruction scheme. As 
shown in this figure at 4600, 1st to 7th and 16th to 23rd physical registers of 
the machine B can be used for the arithmetic operations as represented by 

20 "RcArith". Similarly, there are represented by "RcAddr" at 4602 the physical 
register which can be used for the address calculation, while "RcTemp" at 
4614 represents the physical register used temporally. In this manner, there 
are indicated in Fig. 31 the usages of the physical registers in the machine B 
which differ from those of the machine A shown in Fig. 23. 

25 Fig. 32 is a view showing a part of correspondence relations between 
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the physical registers incorporated in the machine B and the abstract 
registers. Although the abstract registers 4620 may be used in an arbitrary 
number as in the case of the machine A, the number of the physical register 
of the machine B is limited up to thirty-two. The abstract registers 4624 for 
5 placing function values therein are represented by "FuncvalO" and 

"Funcval 1" and correspondences are established to the physical register "8" 
and "9", respectively, as indicated by 463i and 4632. Representing the 
abstract registers 4625 used for placing parameters therein by "ParamO", 
"Paraml", "Praxnp", there are established correspondence relations 

10 between these abstract registers and the physical registers "24" to "29" as 
indicated by 4633 and 4634. The abstract registers 4626 used for arithmetic 
operation and represented by "RrO", "Ar1", "Arq" bear correspondence 
relations to the physical registers "1" to "7" and "16" to "23", as indicated by 
4635, 4636, 3637 and 4638, respectively. Similarly, the abstract registers 

15 4627 used for the address calculation and represented by "AddrO", "Addrl", 
... -, "Addrr", respectively, bear correspondence relations to the physical 
registers "1" to "7" and "16" to "23", as indicated by 4639, 4640, 4641 and 
4642, respectively. 

Fig. 33 is a view showing a part of the machine instruction generating 

20 rules oriented for the machine B. By 10 way of example, the rule 4700 

dictates how to generate the machine instruction in correspondence to the 
ArmCode instruction for the constant loading. The rule 4712 is for the 
machine instruction concerning the loading from a memory. The rule 4716 
indicates how to generate machine instructions for the ArmCode instruction 

25 sequence which dictates that the result obtained from the addition of registers 



Reg1 and Reg2 be placed in the register Reg3. In this way, Fig. 32 shows the 
machine instruction generating rules which are required for translating the 
abstract object program shown in Figs. 20 and 21 into a machine language 
program. Fig. 34 is a view showing the correspondence relations of the 
5 physical registers incorporated in the machine B to the abstract registers in 
the program shown in Figs. 20 and 21, as exemplified at 4780. More 
specifically, there are shown in this figure the results of the register allocation 
by the generation control instructions such as "alloc" , "free", etc.. 

Fig. 35 is a view showing examples of the machine instructions 

10 generated by applying the rules shown in Fig. 33 to the ArmCode instructions 
shown in Figs. 20 and 21. More specifically, referring to Fig. 35, a machine 
instruction 4800 is generated by applying the rule 4700 shown in Fig. 33 to 
the ArmCode instruction 4030 shown in Fig. 20, and a machine instruction 
4802 is generated by applying the rule 4722 to the ArmCode instruction 4032. 

15 In this manner, the installer for the machine B applies the rules shown in Figs. 
20 and 21 to thereby generate the machine language program for the 
machine B as shown in Fig. 35. 

As will now be understood from the above description, the installer for 
the machine A generates the machine language program for the machine A 

20 with the installer for the machine B generating the machine language program 
for the machine B, both from one and the same abstract object program. 
These two installers differ from each other with regard to the applicable 
machine instruction generating rules and the physical register usage 
designations. However, both installers are the same with respect to the 

25 contents of the processing illustrated in Fig. 29. 
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As will be appreciated from the foregoing description, according to the 
instant embodiment of the invention, a major proportion of the global 
optimization processing and the register allocation optimization processing 
are carried out by the compiler which is independent of the target machines, 
5 wherein the information concerning the flow analysis, register allocation and 
others generated by the compiler is transferred to the installer, as a result of 
which the installer can generate the machine language program of improved 
execution performance or efficiency without need for complicated processing. 
Accordingly, even when the target-oriented machine language program is 
10 generated from the machine-independent abstract object program by the 
installer(s) every time the program is activated, there arises substantially no 
problem concerning the execution performance and the processing time taken 
by the installer. 

Further, according to the instant embodiment, software can be 
15 delivered to a plurality of different target machines in the form of the same 
abstract object program without involving the necessity of adjusting the 
software or re-compilation for each of the target machines, whereby 
maintenance and management can be significantly facilitated. 

Moreover, it is noted that according to the instant embodiment of the 
20 invention, the abstract object program is decomposed to very fine levels of 
manipulation when compared with the source program. Besides, the abstract 
object program differs from the source program with regard to the structure as 
well as sequence of the descriptions. For these reasons, it is practically 
impossible to restore the source program from the abstract object program. 
25 Thus, by delivering a software in the form of the abstract object program to 



the users, it is possible for the user to execute one and the same program by 
a plurality of computers or machines and/or change the types of machines as 
used while maintaining in secrecy the software implementation schemes and 
algorithms contained in the source program. 
5 It should be further noted that by using the installer according to the 

present invention, one and the same source-level debug system can be made 
use of by a plurality of machines. An embodiment directed to this feature of 
the invention will be described below by referring to Figs. 36 to 45. 

Fig. 36 is a block diagram showing a structure of a debug system to 

10 which the installer according to the invention is applied. Referring to the 
figure, a debugger 5100 is used for debugging an abstract object program 
5102 generated by compiling a source program 5101. An installer 5103 
implemented according to the teachings of the invention is used for translating 
the abstract object program into a machine language program 5107. A main 

15 memory 5104 is employed for storing the machine language program 5107 
and a debug information table 5108. A display unit 5105 serves for displaying 
the results to the user while an input device 5106 is used for receiving the 
inputs from the user. 

Fig. 37 is a flow chart for illustrating operation of the debugger. At first, 

20 an abstract object program 5102 is read (step 5120). Since the abstract object 
program contains source information indicating positions on the source 
program and others, a source-abstract object correspondence table is 
generated on the basis of the source information (step 5121). Subsequently, 
the installer is operated on the abstract object program as input, to thereby 

25 generate a machine language program on the main memory 1step 5122). In 
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that case, an abstract object-machine language correspondence table is 
generated for establishing correspondence between the abstract object 
program and the machine language program (step 5123). In this conjunction, 
it is noted that in the case of the instant embodiment, the source-abstract 
5 object correspondence table and the abstract object-machine language 
correspondence table are integrated into a single table (referred to as a 
source-abstract object-machine language correspondence table). This table is 
included in the debug information table 5108. When the user inputs a 
command requisite for the debugging (step 5124), the processing flow is 

10 branched in dependence on the type of the input command (step 5125). More 
specifically, when a display command is input, a displaying processing is 
executed (step 5126). For a break point setting command as input, a break 
point setting processing is executed (step 5127), while for an execution 
command, execution processing is performed (step 5128). Upon completion 

15 of these processings, the flow is repeated, starting from the step 5125. The 
command processings mentioned above will be described in more detail by 
reference to Figs. 38 to 43. When the input command is an exit command, the 
processing is terminated. 

Fig. 38 is a view showing an example of the display command. In the 

20 case of this example, the display command is for the value of the variable i. 
The display command, includes a command name PRT 5131 to be displayed 
and a variable name i 5132. 

Fig. 39 is a flow chart for illustrating the display processing in detail. In 
other words, this figure shows details of the processing step 5i26 shown in 

25 Fig. 37. Referring to Fig. 39, the variable name in the display command is 
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extracted (step 5133). Subsequently, by consulting the source-abstract object 
machine language correspondence table (hereinafter referred to simply as 
correspondence table), the variable name is translated into an address on the 
main memory on which the content of that variable is stored, which is then 
5 followed by a step 5135 where the content of the address determined at the 
step 5134 is read out from the main memory (step 5135). Then the content as 
read out undergoes translation in accordance with data type of the variable 
read out to be thereby displayed on the display device. 

Fig. 40 is a view showing an example of the break-point setting 

10 command. More specifically, this exemplary command is for setting a break 
point in the statement numbered "10" in the source program and composed of 
a command name (identifier or ID) 5141 and a statement ID number 5142. 

Fig. 41 is a flow chart for illustrating a break-point setting processing 
and shows details of the processing in the step 5127 shown in Figs. 37. 

15 Referring to Fig. 41 , the statement ID number in the command is extracted 
(step 5143). Thereafter, a flag is set which indicates that the break point has 
been set at the corresponding statement ID number in the correspondence 
table (step 5144). 

Fig. 42 is a view showing an example of execution command, which 

20 commands execution of program and consists only of a command name 
5151. 

Figs. 43 is a flow chart for illustrating execution processing and shows 
details of the processing in the step 5128 shown in Fig. 37. Referring to Fig. 
43, only one instruction is first executed (step 5152). This can be realized by 
25 running a CPU in such a mode that trap is validated every time one instruction 
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has been executed, at this time, the control is transferred back to the 
debugger. Subsequently, address of the instruction is extracted (step 5153), 
which can be realized, for example, by reading out the content of a program 
counter. Finally, in a step 51 54, it is checked by consulting the 
5 correspondence table whether the break point is set at the extracted address. 
Unless the break point is set, the processing is repeated, starting from the 
step 5152, while the processing comes to an end when the break point is set. 

Fig. 44 is a view showing an example of the source program which is 
subject to the debugging. In this figure, the statement numbers 5160 and 
10 descriptions 5161 of the statements in the source program are shown. It 

should be mentioned, however, that the statement number is not contained in 
the actual source program. The following description of the instant 
embodiment will be made on the assumption that the source program shown 
in Fig. 44 is used. 

15 Fig. 45 is a view showing an example of a source-abstract object- 

machine language correspondence table. This correspondence table is 
composed of (a) a statement information table and (b) a variable information 
table. The statement table includes four fields which correspond to the source 
program statement number 5170, the abstract object program instruction 

20 address 5171 , the machine language program instruction address 5172 and 
the break-point set flag 5173, respectively. Referring to Fig. 45A, an entry 
5174, for example, indicates that the statement numbered "10" is an 
instruction located at the address of "000060" in the abstract object program, 
while it is an instruction located at the address of "000040" in the machine 

25 language program and that a break point is set in this statement. 



65 



The variable information table shown in Fig. 45B includes five fields for 
a variable name 5175, a variable type 5176, a data type 5177, a line number 
5178 and a machine address 5179, respectively. The variable names 5185 
represent names of variables in the source program. The variable types 5176 
5 represent discriminatively local variables and global variables. The data type 

5177 represents the data types 5177 of the variables. The statement number 

5178 represents the position on the source program at which the variable has 
been declared. The machine language address 5179 is the information of the 
address of the variable on the machine language program and represents an 

10 offset from a frame pointer in the case of the local variable while representing 
an offset from a base address of the variable area in the case of the global 
variable. By way of example, an entry 5180 indicates that the variable i is a 
local variable, the data type is "int" which is located in the statement 
numbered "4" of the source program and that the offset from the frame pointer 

15 on the machine language program is "-4". 

As will be understood from the above description, the debug system 
according to the illustrated embodiment of the invention can enjoy an 
advantageous effect that one and the same abstract object program can be 
debugged by plural types of systems because the installer is incorporated for 

20 translating the machine-independent abstract object program into an target 
machine language program. 

By utilizing the installer according to the invention, the abstract object 
program can be supplied in the form of IC card or CD-ROM or the like so as to 
provide a machine-independent offhand-executable -system. For example, by 

25 incorporating a game program in an IC card while incorporating the installers 
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in individual machines, respectively, it is possible to execute one and the 
same game program by different machines (IC card systems). An exemplary 
embodiment of such system will be described below by reference to Figs. 46 
to 50. 

5 Fig. 46 is a block diagram showing a structure of an IC system 

incorporating an installer according to the invention. The IC card system 
shown in this figure includes a controller 5000, a main memory 5002, an IC 
card read/write device 5005, a keyboard 5006 and a display 5007. The 
controller 5000 incorporates therein a CPU 5001 . On the other hand, the main 

10 memory 5002 incorporates an installer 5003. An IC card 5008 is coupled to 
the IC card system via the IC card read/write device 5005. The program 
stored in the IC card is loaded into the main storage as a machine language 
program 5004 through the medium of the installer 5003. 

Fig. 47 is a pictorial view showing an outer appearance of the IC card 

15 system. A user can input data with the aid of the keyboard 5006, while 
response to the user is displayed on the display unit 5007. The IC card is 
inserted through an IC card insertion slot 5009. 

Fig. 48 is a top plane view of the IC card 5008. Data transactions 
between the IC card and the IC card read/write device are realized via contact 

20 points 5010. A storage device 501 1 stores an abstract object program 5012 
20 to be executed and data 5013. 

Fig. 49 is a flow chart for illustrating execution of the abstract object 
program incorporated in the IC card. In the first place, the IC card 5008 is 
inserted into the IC card slot 5009 (step 5020) to read out the abstract object 

25 program and the data stored in the IC card (step 5021). In response to the 
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inputting of the abstract object program read out from the IC card, the 
controller 5000 activates the installer 5003 (step 5022). As a result, there is 
generated in the main memory the target machine language program 5004, 
which is then executed (step 5023). As a result of the execution, the resulting 
5 data is written in the IC card, if it is required, in a step 5024, and the IC card is 
returned (step 5025). At this time the transaction comes to an end. 

Fig. 50 is a block diagram showing a system in which one and the 
same abstract object program contained in an IC card is executed by a 
plurality of IC card apparatus having different CPUs, respectively, according 

10 to an embodiment of the invention. It is assumed, by way of example, that the 
illustrated system includes IC card apparatuses A and B which incorporate in 
the respective controllers a CPU-A 5038 and a CPU-B 5039 which have 
mutually different instruction schemes, respectively. When the abstract object 
program placed in the IC card 5008 is to be used in the IC card apparatus A, 

15 the abstract object program is translated into a machine language program A 
5036 described in the CPU-A-oriented machine language. On the other hand, 
when the abstract object program of the IC card 5008 is to be used in the IC 
card abstract object program the former is translated into a machine language 
program B 5037 described in a CPU-B-oriented machine language. 

20 Although it has been assumed in the above description that the IC card 

is used as the medium for storing and carrying the abstract object program, it 
should be appreciated that the present invention can equally be applied to the 
systems in which CD-ROM, floppy disk or the like is used. 

Fig. 51 is a block diagram showing a system in which ArmCode 

25 programs are shared by computer systems of different types which are linked 



together through a network. 

Connected to a network medium 1 101 are a file server 1 102 and 
computer systems which are exemplified by a computer system A 1 103 and a 
computer system B 1 104. A disk device 1 105 is connected to the file server 
5 1 1 02 which serves for supplying file data from the disk device 1 1 05 to the 
computer systems A and B (1 103 and 1 104). Each of the computer systems A 
and B can make access to the files on the disk device 1 105 with the aid of 
their own remote file management programs (1106, 1107). Further, the 
computer systems A and B incorporate respective instructions (1 108, 1 109) 

10 for translating the ArmCode program into machine language programs 
oriented to these computer systems, respectively. 

When an ArmCode program 1 1 10 on the disk device 1 105 is to be 
executed by the computer system A, the ArmCode program 1110 made 
available through the associated remote file management program 1106 is 

is translated into a machine language program 1111 by the installer 1 108 to be 
subsequently executed by the computer system A. Similarly, a machine 
language program 1 1 12 is generated for execution by the computer system B 
as well. 

In this manner, one and the same ArmCode program can be executed 
20 by a plurality of computers of different types connected to the network, which 
means that commonality of the object program is realized. 

In the prior art system, it was impossible to make an object program 
common to the machines of different types, making it necessary for each 
machine to hold an object program having a same function. In contrast, by 
25 consolidating the object program files required for every types of the machine 
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for a certain function in an ArmCode program file as described above, there 
can be assured advantages mentioned below. 

(1 ) File capacity of a whole network system can be reduced. 

(2) The bug correction and extension of function may be performed only 

5 for the ArmCode program without necessitating simultaneous execution for a 
plurality of object programs, whereby time and labor for version management 
of the object programs can be reduced drastically. 

Fig. 52 is a block diagram for explaining replacement of a computer 
system in which an ArmCode program is employed by another type of 
10 computer system. 

Referring to the figure, it is assumed that in a computer system A 1201 , 
a machine language program running thereon is stored on an associated disk 
device 1202 in the form of ArmCode program. In other words, when a certain 
function is to be implemented by the computer system A 1201 , the ArmCode 
15 program 1204 on the disk system 1202 which corresponds to the function is 
translated into a machine language program 1205 oriented for the system A 

1201 by an installer 1203 for execution. 

This type of computer system can easily be replaced by another 
computer system which incorporates an installer. Namely, replacement of the 
20 computer system A 1201 by another system B 1206 can readily be 

accomplished only by copying the ArmCode program 1204 on the disk device 

1202 onto a disk device 1207. Thus, when a certain function implemented by 
the computer system A 1201 is to be implemented by the computer system B 
1206, the ArmCode program corresponding to that function and copied onto 

25 the disk device 1207 is translated into a machine language program 1209 by 



70 



the installer 1208 to be subsequently executed. 

By adopting the ArmCode as a scheme for reserving programs on the 
disk, advantages mentioned below can be is obtained. 

(1 ) For the user, the time and labor involved in exchange or switching of 
5 the computer systems such as recompiling of source program and 

regeneration of machine language programs can considerably be reduced. 

(2) For the manufactures, a system design for maximizing computer 
performances can be facilitated because of capability of generating the 
machine language without need for taking into account the exchangeability or 

10 switchability of the computer system. 

As will now be appreciated from the foregoing description, it is possible 
according to the teachings of the present invention to generate a machine 
language instruction sequence by effectively making use of the real machine 
registers by virtue of optimization of abstract register usage by the compiler 

15 and the real register allocating function of the installer. Moreover, owing to the 
instruction language pattern replace function of the installer, high-level 
functional instructions of the real machine can effectively be utilized. 
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